ハイブリッドクラウドかつマルチアカウント構成で、Route 53 Resolver イン / アウトバウンドエンドポイントの集約

はじめに

オンプレミス環境とクラウド環境のハイブリッド構成、かつマルチアカウント構成で、Route 53 Resolverのアウトバウンドエンドポイントとインバウンドエンドポイントを1つのVPCに集約する構成を構築する機会がありましたので、その概要をまとめました。

実際の構築では、構築手順が記載された記事を参考にしましたので、本記事では構成内容の説明に留め、実際の構築手順については参考にした記事を紹介します。

Route 53 Resolverの概要は、下記の記事がわかりやすいです。DNSの基本から解説されています。

以降は、Route 53 Resolver インバウントエンドポイントは、インバウントエンドポイント、Route 53 Resolver アウトバウントエンドポイントは、アウトバウンドエンドポイントと省略します。

集約構成

集約構成は下記の通りです。

共通アカウントにアウトバウンドエンドポイントとインバウンドエンドポイントを集約し、複数のメンバーアカウントではエンドポイントを作成しません。

今回のインバウンド/アウトバウンドエンドポイントの集約においては、VPCピアリングやTransit Gatewayなどで、アカウント同士の接続は不要です。

ただし、インバウンド/アウトバウンドエンドポイント以外にもVPCエンドポイントの集約やNAT Gatewayによるインターネットへの出口の集約を利用する場合は、メンバーアカウントと共通アカウントの接続が必要になります。

インバウンドエンドポイントとアウトバウンドエンドポイント、それぞれの構築手順と経路を解説します。

インバウントの集約

オンプレミスのサーバーからAWS環境内のプライベートドメインで名前解決を行いたい場合、インバウンドエンドポイントを利用します。

プライベートドメインは、Route 53 プライベートホストゾーン（以降、プライベートホストゾーン）で定義します。

名前解決の経路は、オンプレミスサーバーからフォワーダーとインバウンドエンドポイントを経由し、メンバーアカウントのプライベートホストゾーンで行います。

名前解決に成功すると、EC2インスタンスのプライベートIPが取得され、EC2インスタンスへの通信が成功します。

インバウンドエンドポイントの集約を実現するために必要な構築手順は以下の通りです。

1. メンバーアカウントでプライベートホストゾーンを作成し、ドメイン名とEC2インスタンスのプライベートIPを登録してVPCに関連付けます。
2. 共通アカウントで、セキュリティグループとインバウントエンドポイントを作成します。
3. オンプレミスのフォワーダー設定にプライベートホストゾーンのドメイン名を追加し、転送先としてインバウンドエンドポイントのIPアドレスを登録します。
4. メンバーアカウントのプライベートホストゾーンを共通アカウントのVPCに関連付けます。

1.~3.の構築手順は、こちらの記事が参考になります。

4.の構築手順は、こちらの記事が参考になります。

別のメンバーアカウントのプライベートホストゾーンで名前解決を行いたい場合は、そのメンバーアカウントのプライベートホストゾーンも共通アカウントのVPCに関連付けることで実現できます。

この方法で共通アカウントのVPCにメンバーアカウントのプライベートホストゾーンを関連付けることで、インバウンドエンドポイントを集約できます。

インバウンドエンドポイントではリゾルバールールを追加で作成する必要はありません。

追記
上記は、各リソースアカウントごとにプライベートホストゾーンを作成し集約する方法です。
以下の構成の構成の通り、共通アカウントに1つのプライベートホストゾーンのみで集約する方法も紹介します。

まず、共通アカウントで1つプライベートホストゾーンを作成します。ドメイン名は何でもよいですが、aws.localとします。

各アカウントの(Aアカウント、Bアカウント)のEC2インスタンスのプライベートIPに対して、レコード名をa-ec2.aws.localやb-ec2.aws.localで登録することで、共通アカウントのプライベートホストゾーンのみで実現できます。

各アカウントにプライベートホストゾーンを作成するよりも、関連付け作業が不要かつランニングコストが下がります。

プライベートホストゾーン1つあたり、0.50 USD/月 (最初の 25 個のホストゾーン)のコストがかかります。

アウトバウントの集約

AWS側でEC2インスタンスなどのサーバーから、オンプレミスのネームサーバーで名前解決を行いたい場合、アウトバウンドエンドポイントを利用します。（下記の場合、example.org）

名前解決の経路は、メンバーアカウントのEC2インスタンスからRoute 53 Resolverのフォワーダーとアウトバウンドエンドポイントを経由し、オンプレミスのネームサーバーで行われます。

アウトバウンドエンドポイントの集約を実現するために必要な構築手順は、下記の通りです。

• 共通アカウントで、セキュリティグループとアウトバウンドエンドポイントを作成します。
• 共通アカウントで、Route 53 リゾルバルールを作成します。
  • リゾルバールールは、オンプレミスのネームサーバーで名前解決したいドメイン名(example.org)指定し、ルールタイプを転送タイプに設定します。転送先であるオンプレミス側のIPアドレスも指定します。
• 共通アカウントで作成したリゾルバールールをメンバーアカウントでも利用できるように、Resource Access Managerでリゾルバールールを共有します。
  • AWS Organizationsを利用している場合、組織内の全アカウントと共有することもできます。
• メンバーアカウントで、メンバーアカウントのVPCにリゾルバールールを関連付けます

1.~4.の手順は、下記の記事が参考になりました。

[補足1] アウトバウンドエンドポイントのセキュリティグループの設定は、インバウンドルールが不要で、アウトバウンドルールは以下の通りです。

タイプ	プロトコル	ポート範囲	ソース（CIDR）	備考
DNS(TCP)	TCP	53	x.x.x.x/32	ネームサーバー
DNS(TCP)	UDP	53	x.x.x.x/32	ネームサーバー

[補足2] アウトバウンドエンドポイントを作成したサブネットに関連付けられたルートテーブルには、オンプレミスへのルートを設定してください。

送信先	ターゲット	備考
x.x.x.x/32	vgw-xxxxx	送信先はネームサーバーのIPアドレス

最後に

複数アカウント間やAWSとオンプレミスで実行されるワークロード間でドメインの名前解決を行うRoute 53 Resolverのインバウンド/アウトバウンドエンドポイントの集約構成について解説しました。

集約することでコスト削減や運用負担の軽減に繋がるため、参考にしていただければ幸いです。

参考